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METHOD AND APPARATUS FOR PROCESSING A CHARGE 
APPLIED TO A FINANCIAL ACCOUNT 



CROSS-REFERENCE TO RELATED APPLICATIONS 

The following commonly owned, co-pending applications, Patent Application Serial No. 
08/883,308, entitled "SYSTEM AND METHOD FOR ESTABLISHING AND EXECUTING 
FUNCTIONS TO AFFECT CREDIT CARD ACCOUNTS AND TRANSACTIONS ", filed 

June 26, 1997, and Patent Application Serial No. , Attorney Docket No. WD2-97-134, 

entitled "METHOD AND SYSTEM FOR CONTROLLING AUTHORIZATION OF CREDIT 
CARD TRANSACTIONS", filed March 6, 1998, are incorporated by reference herein as part of 
the present disclosure. 

FIELD OF THE INVENTION 

The present invention relates to methods and apparatus for processing charges 

applied to financial accounts. 

BACKGROUND OF THE INVENTION 

Many people are reimbursed by third parties for their purchases. In many cases, 
such reimbursement arises from a business relation. For example, an employer may reimburse 
an employee's purchases that are business related. Similarly, an insurer may reimburse all or 
some portion of an insured party's medical expenses. 

The reimbursing party typically requires documentation to verify (i) that the 
stated amount was actually spent on the purchase, and (ii) that the purchase is of the type that the 
reimbursing party is willing to pay for. A party to be reimbursed may submit receipts that 
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support his request for reimbursement. The reimbursing party in turn evaluates the submitted 
documentation, and approves or rejects the request for reimbursement. 

Many people use "card-based" financial accounts, such as credit card accounts 
and debit card accounts, to pay for their purchases. Such card-based financial accounts can 
5 provide a secure, flexible and convenient way to pay for many purchases. Parties that use such 
card-based financial accounts typically receive paper "charge slips" for each transaction (e.g. a 
purchase or a refund), as well as monthly billing statements documenting transactions made with 
the card-based financial account. Accordingly, purchases made with card-based financial 
accounts can readily support requests for reimbursement. 
1 o Unfortunately, known processes for evaluating and approving requests for 

reimbursement suffer substantial shortcomings. Most reimbursing parties are not able or willing 
to rapidly process documentation supporting requests for reimbursement. Data entry, 
bureaucratic procedures and manual evaluation of documentation delay the eventual approval or 
rejection of a request for reimbursement. In addition, data entry may introduce errors, and 
1 5 documentation may be misplaced by either the reimbursing party or the party to be reimbursed. 
Consequently, the party to be reimbursed may wait long periods of time after a purchase before 
receiving the corresponding reimbursement. In addition, the reimbursing party often incurs 
substantial costs in processing requests for reimbursement. 

Further shortcomings are particular to parties that use card-based financial 
2 0 accounts. Charge slips and billing statements typically identify the financial account, for 
example, by credit card account number. Thus, submitting such documentation reveals the 
financial account to many parties involved in reimbursement approval, and the financial account 
may therefor become more susceptible to fraudulent use. Blocking the credit card account 
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number from copies of such documentation can be time-consuming and error-fraught for the 

party to be reimbursed. 

In addition, charges to a card-based financial account may be increased by interest 
and other penalties if the reimbursing party does not provide reimbursement in a timely manner. 
5 Thus, the party to be reimbursed may be forced to pay amounts for which he may never be 
reimbursed. In addition, even if reimbursement is forthcoming, a card holder may have a large 
amount of charges to be reimbursed. Consequently, he may be close to his balance limit and 
unable to apply further charges to his account. 

To support reimbursement, many employers provide employees with "corporate" 
1 0 credit cards. Corporate credit cards, issued by banks to employers, enable employees to conduct 
business at the employer's expense. For example, a corporate credit card may be used to 
purchase entertainment for clients, supplies and travel services. However, employees may abuse 
the spending privileges afforded by corporate credit cards. Consequently, many employers must 
thoroughly audit billing statements to ensure the proper use of corporate credit cards. As 
1 5 described above, processing the documentation that supports a request for reimbursement can be 
burdensome, time consuming and inaccurate. In addition, some types of corporate cards impose 
liability for all charges on the reimbursing party, which is often undesirable. 

To attempt to limit corporate credit card abuse, some corporate credit cards enable 
the employer to prevent certain types of purchases. For example, First Bank's "Corporate 
2 0 Relocation Card" allows employers to give their employees corporate credit cards to use when 
relocating. Employers can prevent use of the corporate credit card at certain merchant types, 
such as bars and casinos. Typically, the issuing bank stores a list of any SIC codes (Standard 
Industrial Classification codes) or MCCs (Merchant Category Codes) that have been selected to 
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be disallowed by the employer. When the bank receives a request to authorize a charge on the 
employee's corporate credit card, the bank verifies that the corresponding merchant code is not 
disallowed. Unfortunately, preventing use of the corporate credit card at certain merchant types 
does not prevent the employee from overspending at an allowed merchant. 
5 Some accounting software is designed to make auditing corporate credit card 

accounts more accurate or efficient. For example, Visa provides InfoSpan 2.0 Intelligent 
Information Management software for use in managing "Visa Corporate" and "Visa Purchasing" 
accounts. The software is intended to enable employers to "streamline accounting processes" 
and "reduce administrative expenses," as well as "ensure card spending complies with company 
10 policy." 

While these products may facilitate the management of corporate credit card 
accounts, reimbursement will typically remain a lengthy process, and abuse of reimbursement 
privileges can continue with known systems and methods for reimbursement. It would be 
advantageous to make the reimbursement process more efficient and convenient for both 
1 5 reimbursing parties and parties to be reimbursed. 

SUMMARY OF THE INVENTION 

It is an object of the present invention to make the reimbursement process more 
efficient and convenient for both reimbursing parties and parties to be reimbursed. 
20 In accordance with the present invention, a billing server receives charge data 

from a card authorization terminal. The charge data indicates a transaction amount, such as a 
purchase price, and a first financial account, such as a credit card account. The billing server 
determines a second financial account that corresponds to the first financial account. For 
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example, the second financial account may be the financial account of an insurance company or 
other reimbursing party. The billing server also determines a reimbursement amount that 
corresponds to the first financial account, and the second financial account is charged the 
reimbursement amount. Thus, a portion or all of the transaction amount is paid by a reimbursing 
5 party. 

The second financial account is charged only if a reimbursement rule is satisfied. 
For example, only purchases made at certain types of merchants may be reimbursed. In addition, 
the billing server may first request approval (e.g., from the reimbursing party) before charging 
the second financial account. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic illustration of an embodiment of a reimbursement system 
provided in accordance with the present invention. 

FIG. 2 is a schematic illustration of a billing server of the reimbursement system 

15 of FIG. 1. 

FIG. 3 is a schematic illustration of an account holder database of the billing 
server of FIG. 2. 

FIG. 4 is a schematic illustration of a reimbursing party database of the billing 
server of FIG. 2. 

2 o FIG. 5 is a schematic illustration of an exemplary record of a transaction database 

of the billing server of FIG. 2. 

FIG. 6 is a schematic illustration of an exemplary record of a reimbursement rules 

database of the billing server of FIG. 2. 



5 



FIG. 7 is a schematic illustration of an exemplary record of a billing statement 

database of the billing server of FIG. 2. 

FIG. 8 is a flowchart illustrating a method for processing a charge applied to a 

financial account. 

5 FIG. 9 is a schematic illustration of another embodiment of a reimbursement 

system provided in accordance with the present invention. 

FIG. 10 is a schematic illustration of another embodiment of a record of the 
reimbursement rules database of the billing server of FIG. 2. 

FIGS. 1 1 A and 1 IB are a flowchart illustrating another method for processing a 

1 0 charge applied to a financial account. 

FIG. 12 is a schematic illustration of an exemplary record of another embodiment 
of the billing statement database of the billing server of FIG. 2. 

FIG. 13 is a plan view of an exemplary billing statement printed in accordance 

with the present invention. 
1 5 FIG. 14 is a plan view of another exemplary billing statement printed in 

accordance with the present invention. 

FIG. 15 is a schematic illustration of an account alias database. 

FIG. 16 is a flowchart illustrating another method for processing a charge applied 
to a financial account. 

20 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

A method and apparatus are provided whereby a portion or all of a transaction 
amount is charged to the account of a reimbursing party. Compared to known methods and 
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apparatus for reimbursement, the present invention makes the reimbursement process more 
efficient and convenient for both reimbursing parties and parties to be reimbursed. Such 
reimbursement may be driven by a business relation, such as when an employer reimburses an 
employee's purchases, or when an insurer reimburses all or some portion of an insured party's 
5 medical expenses. Alternatively, such reimbursement may be driven by generosity or altruism, 
such as when a relative pays for a gift, or when an employee's donation is matched according to 
an employer gift-matching program. 

Although the term reimbursement and other variations thereof is used herein, 
those skilled in the art will understand that such terms are convenient labels that do not 
1 0 necessarily imply that there is compensation for money spent or losses incurred by another. 

Referring to FIG. 1, in one embodiment a reimbursement system 10 includes a 
card authorization terminal 12 that is in communication with a billing server 14. The card 
authorization terminal ("CAT") 12, such as those manufactured by VeriFone, Inc., is a device for 
reading information stored on cards, such as credit cards having magnetically-encoded strips, and 
1 5 transmitting that information to the billing server 14. Information read from cards typically 
includes an identifier that identifies a financial account, such as a credit card account identifier 
read from the magnetically-encoded strip, and a transaction amount, such as a purchase price. 
The CAT 12 is used with such cards in adjusting the balance of the corresponding financial 
account of the cards. 

2 0 In a credit card account, the balance is typically an amount of debt, with the 

balance increasing and decreasing as amounts of debits and credits respectively are applied to the 
credit card account. In a debit card account, the balance is typically an amount of funds 
available, and the balance can increase and decrease as amounts of credits and debits 
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respectively are applied to the debit card account. For example, the card may be used during a 
transaction to apply an amount of debit to the financial account, such as when a purchase is paid 
for using the financial account. The card may also be used during a transaction to apply an 
amount of credit to the financial account, such as when merchandise is returned and a refund for 
the merchandise is applied to the financial account. As used herein, "applying a charge amount" 
and "charging" each mean applying a debit amount to a financial account. 

The billing server 14 is a computing device that is controlled by or on behalf of a 
billing party, which is typically an issuer of the financial account. The billing server 14 receives 
the information transmitted by the CAT 12, and may adjust the indicated financial account by the 
indicated amount. The billing server 14 in turn transmits to the CAT 12 an indication that the 
financial account has been adjusted. For example, during a transaction a typical card 
authorization terminal may receive an authorization code for the transaction, in which the 
authorization code indicates that a requested debit amount has been applied to the financial 
account and therefor the transaction has been authorized. 

Referring to FIG. 2, the billing server 14 comprises a processor 20, such as one or 
more conventional microprocessors. The processor 20 is in communication with a data storage 
device 22, such as an appropriate combination of magnetic, optical and/or semiconductor 
memory. The processor 20 and the storage device 22 may each be (i) located entirely within a 
single computer or other computing device; (ii) connected to each other by a remote 
communication medium, such as a serial port cable, telephone line or radio frequency 
transceiver; or (iii) a combination thereof. For example, the billing server 14 may comprise one 
or more computers that are connected to a remote server computer for maintaining databases. 
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An input device 24 and a printer 26 are each in communication with the processor 
20. The input device 24 may comprise a keypad for transmitting input signals, such as signals 
representative of operator commands, to the processor 20. The printer 26 is for registering 
indicia on paper or other material, thereby printing billing statements as commanded by the 
5 processor 20. Many types of input devices and printers are known to those skilled in the art, and 
need not be described in detail herein. 

The storage device 22 stores a program 28 for controlling the processor 20. The 
processor 20 performs instructions of the program 28, and thereby operates in accordance with 
the present invention, and particularly in accordance with the methods described in detail herein. 
1 0 The program 28 furthermore includes program elements that may be necessary, such as an 

operating system and "device drivers" for allowing the processor 20 to interface with computer 
peripheral devices, such as the input device 24 and the printer 26. Appropriate device drivers 
and other necessary program elements are known to those skilled in the art, and need not be 
described in detail herein. 
1 5 The storage device 22 also stores (i) an account holder database 30; (ii) a 

reimbursing party database 32; (iii) a transaction database 34; (iv) a reimbursement rules 
database 36; and (v) a billing statement database 38. The databases 30, 32, 34, 36 and 38 are 
described in detail below and depicted with exemplary entries in the accompanying figures. As 
will be understood by those skilled in the art, the schematic illustrations of, and accompanying 
2 0 descriptions of the databases presented herein are exemplary arrangements for stored 

representations of information. A number of other arrangements may be employed besides the 
tables shown. In addition, information which is illustrated as being stored in one database may 
be stored in one or more other databases. Similarly, the illustrated entries represent exemplary 
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information, but those skilled in the art will understand that the number and content of the entries 
can be different from those illustrated herein. 

In the description below, financial accounts which are credit card accounts are 
described and used in conjunction with the present invention. Those skilled in the art will 
understand that the present invention is equally applicable to other types of financial accounts, 
such as debit card accounts or stored value cards such as "smart cards". 

Referring to FIG. 3, a table 50 illustrates an embodiment of the account holder 
database 30 (FIG. 2). The table 50 includes entries 52, 54, 56, 58, 60 and 62, each of which 
describes a party to be reimbursed that has a financial account with the billing party. Such a 
party to be reimbursed is also referred to herein as an "account holder". It will be understood by 
those skilled in the art that the table 50 may include any number of entries. Each of the entries 
52, 54, 56, 58, 60 and 62 defines (i) an account identifier 64 for uniquely indicating the financial 
account; (ii) an account holder name 66; (iii) an account holder billing address 68; (iv) a 
maximum balance 70; and (v) an available balance 72. The maximum balance 70 is the 
maximum balance allowed on the financial account at any time. Similarly, the available balance 
72 is the difference between the maximum balance and the current balance of the financial 
account. For example, referring to the entry 54, the financial account identified by "1 1 1 1-1 122- 
2222-2222" has a $7,000 maximum balance and a $3,000 available balance. Accordingly, the 
current balance of the financial account identified by "1 1 1 1-1 122-2222-2222" is $4,000 ($7,000 
- $3,000 = $4,000). As will be apparent to those skilled in the art, further information, such as 
account holder telephone numbers, may be stored for each account holder. 

Referring to FIG. 4, a table 80 illustrates an embodiment of the reimbursing party 
database 32 (FIG. 2). The table 80 includes entries 82, 84, 86 and 88, each of which describes a 
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reimbursing party (a party that has agreed to pay the billing party for at least portions of certain 
transactions initiated by a party to be reimbursed). It will be understood by those skilled in the 
art that the table 80 may include any number of entries. Each of the entries 82, 84, 86 and 88 
defines (i) a reimbursing party identifier 90 for uniquely indicating the reimbursing party; (ii) a 
reimbursing party descriptor 92 for describing the name of the reimbursing party, or other 
information identifying the reimbursing party; and (iii) a total amount due 94 which indicates the 
total amount that the reimbursing party has agreed to pay the billing party but has not yet paid. 
A reimbursing party may have agreed to pay for many transactions initiated by a party to be 
reimbursed. Similarly, a reimbursing party may have agreed to pay for transactions initiated by 
many parties to be reimbursed. Accordingly, the total amount due 94 may be a sum of several 
payments that are due. As will be apparent to those skilled in the art, further information, such 
as a detailed breakdown of the amounts the reimbursing party has agreed to pay and the account 
identifiers of the corresponding parties to be reimbursed, may be stored for each reimbursing 
party. 

Each reimbursing party has agreed to pay the billing party for at least portions of 
certain charges initiated by a party to be reimbursed. The billing party maintains a record of how 
much each reimbursing party owes the billing party. The billing party may also periodically 
send a bill to each reimbursing party or otherwise notify each reimbursing party how much is 
owed. Accordingly, the billing party maintains a financial account for each reimbursing party. 
Such a financial account of the reimbursing party may be uniquely identified by the reimbursing 
party identifier 90, or alternatively by another identifier. The financial account of the 
reimbursing party may be a credit card account or debit card account with the billing party. 
However, the financial account of the reimbursing party need not be a card-based financial 
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account. On the contrary, the financial account of the reimbursing party need not be an account 
which affords the reimbursing party with any spending privileges. The financial account of the 
reimbursing party may simply be a record of how much is owed to the billing party, and may be 
a tool for auditing only. The financial account of the reimbursing party has a balance indicating 
the amount owed, and the balance can increase and decrease as amounts of debits and credits 
respectively are applied to the financial account. 

Referring to FIG. 5, a table 100 illustrates a record included in an embodiment of 
the transaction database 34 (FIG. 2). The transaction database 34 will typically include a 
plurality of records, each defining the transactions in which a particular financial account of an 
account holder was used. The table 100 includes an account identifier 102 that uniquely 
identifies the financial account, and which corresponds to an account identifier of the account 
holder database 30 (FIG. 2). In the exemplary record depicted in FIG. 5, the account identifier is 
"1111-1111-1111-1111", which corresponds to the account identifier of the entry 52 (FIG. 3) of 
the account holder database 30. 

The table 100 also includes entries 104, 106 and 108, each of which describes a 
transaction in which the financial account was used. It will be understood by those skilled in the 
art that the table 100 may include any number of entries. Each of the entries 104, 106 and 108 
defines (i) a transaction identifier 110 that uniquely indicates the transaction; (ii) a merchant 
identifier 1 12 that indicates the merchant that participated in the transaction with the account 
holder; (iii) a POS identifier 1 14 that indicates the point-of-sale terminal (if any) used in the 
transaction; (iv) a transaction date 116 indicating when the transaction occurred; (v) a transaction 
description 1 1 8 that specifies various information regarding the transaction, such as the SIC code 
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of the merchant and/or the name of the merchant; and (vi) the transaction amount 120. As will 
be apparent to those skilled in the art, further information may be stored for each transaction. 

Referring to FIG. 6, a table 130 illustrates a record included in an embodiment of 
the reimbursement rules database 36 (FIG. 2). The reimbursement rules database 36 will 
typically include a plurality of records. Each record defines the reimbursement rules for a 
financial account of an account holder. The table 130 includes an account identifier 132 that 
uniquely identifies the financial account, and which corresponds to an account identifier of the 
account holder database 30 (FIG. 2). In the exemplary record depicted in FIG. 6, the account 
identifier is "111 1-1 111-111 1-1 1 11", which corresponds to the account identifier of the entry 52 
(FIG. 3) of the account holder database 30. 

The table 130 also includes entries 134, 136, 138 and 140, each of which 
describes a reimbursement rule. It will be understood by those skilled in the art that the table 
130 may include any number of entries. Each of the entries 134, 136, 138 and 140 defines (i) a 
reimbursing party identifier 142 that uniquely indicates a reimbursing party, and which 
corresponds to a reimbursing party identifier 90 (FIG. 4) of the reimbursing party database 32; 
(ii) a reimbursement condition 144; (iii) a reimbursement amount 146; (iv) a billing destination 
148 indicating where a bill is to be sent; (v) a time to reimburse 150; (vi) an account alias 152; 
and (vii) an allowed frequency of reimbursable transactions 154. As will be apparent to those 
skilled in the art, further information may be stored for each reimbursement rule. 

Each reimbursement rule indicates how a transaction amount is apportioned 
among a plurality of financial accounts, such as among an account of a reimbursing party and an 
account of a party to be reimbursed. In the above-described embodiment, each reimbursement 
rule specifies a reimbursement amount, which is at least a portion of an account holder's 
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transaction amount to be paid by the reimbursing party if the transaction satisfies the 
reimbursement condition. Some representative conditions are illustrated in FIG. 6 and described 
below. 

One reimbursement condition may be that a particular merchant participates in the 
transaction. For example, the entry 134 has a condition that is satisfied if the merchant that 
participated in the transaction is "Joe's Office Supplies". As described above, the merchant may 
be indicated by the merchant identifier 1 12 (FIG. 5) of the transaction database 34. Thus, it 
would be determined whether the merchant identifier from indicated reimbursement rule of the 
reimbursement rules database 36 corresponds to the merchant identifier of the transaction 
database 34. 

Another reimbursement condition may be that the merchant participating in the 
transaction belongs to a particular category, such as may be indicated by an SIC code. For 
example, the entry 136 has a condition that is satisfied if the merchant that participated in the 

transaction is a restaurant. 

Another reimbursement condition may be that the transaction indicate that a 
certain item or type of item is purchased. For example, the CAT 12 (FIG. 1) may use the 
MasterCard Purchasing Card Level III protocol to transmit data identifying the items purchased 

to the billing server 14 (FIG. 1). 

Another reimbursement condition may be that the transaction amount is (i) within 
a predetermined range, (ii) less than a predetermined amount, or (Hi) equal to a predetermined 
amount. For example, one reimbursement condition may be that the transaction amount is less 
than $100. 
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Those skilled in the art will realize that a condition may comprise two or more 
conditions that are connected by Boolean operations, such as "AND", "OR" and "NOT". For 
example, a condition may be satisfied if the merchant that participated in the transaction is "Joe's 
Office Supplies" and the transaction amount is less than $100. 

Some reimbursement rules may specify that any transaction satisfies the 
reimbursement condition. Accordingly, all transactions using the corresponding financial 
account would be reimbursed if no other restrictions are imposed. For example, the entry 140 
has a condition that is always satisfied. 

The reimbursement amount may be a specified amount (e.g. $10), a variable 
amount (e.g. the transaction amount), or a fixed portion (e.g. 10% of the transaction amount). 
The reimbursement amount may further be subject to a specified maximum amount, such as 
"transaction amount, up to $100" or "10% of the transaction amount, up to $30". The 
reimbursement amount may be based on past transactions. For example, the reimbursement 
amount may be 90% of the portion of the transactions of the year that exceed $1000. In some 
embodiments, the reimbursement amount may be determined by a specified "function code", as 
disclosed in commonly-owned U.S. application Serial No. 08/883.308, entitled "SYSTEM AND 
METHOD FOR ESTABLISHING AND EXECUTING FUNCTIONS TO AFFECT CREDIT 
CARD ACCOUNTS AND TRANSACTIONS", filed on June 26, 1997, incorporated by- 
reference. For example, the reimbursement amount may be determined by a function code (also 
known as a "POS code") which indicates a $10 reimbursement by the reimbursing party. Such 
POS codes may be advantageously used by a merchant to provide customers with discounts. 
Ideally, a corresponding reimbursement condition is that the merchant participate in the 
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transaction. Thus, the reimbursement amount is only provided when the customer conducts a 
transaction with the merchant. 

Each reimbursement rule also specifies a time within which the reimbursing party 
must remit payment to the billing party. Such a time to reimburse is typically measured from the 
time that a corresponding billing statement is sent to the reimbursing party. The time to 
reimburse may also be measured from the time of the transaction. If the reimbursing party does 
not remit payment to the billing party in time, then the amount that was to be paid by the 
reimbursing party is typically charged to the account holder. In such a situation, the account 
holder is ultimately liable for paying debt accrued on the financial account. In other 
embodiments, the account holder is not liable for paying such debt. Accordingly, if the 
reimbursing party does not remit payment in time, the billing party may take steps to collect such 
payment from the reimbursing party. 

The allowed frequency of reimbursable transactions 1 54 of a reimbursement rule 
specifies how often a transaction amount may be reimbursed according to the reimbursement 
rule. For example, the entry 134 specifies that a transaction may be reimbursed according to this 
reimbursement rule once only, the entry 136 specifies that transactions may be reimbursed 
according to this reimbursement rule twice per week, and the entry 138 specifies that 
transactions may be reimbursed according to this reimbursement rule any number of times 
without limit. The entry 140 specifies that a transaction may be reimbursed once, and thus the 
specified POS code may only be used with one transaction. Those skilled in the art will realize 
that a reimbursement rule may specify that a POS code is used any number of times. 

Each reimbursement rule also specifies an account alias. As is described in 
further detail below, an account alias is an identifier that corresponds to, but is not identical to, 
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the account identifier 132. Such an account alias may be provided on the billing statement that is 
sent to the reimbursing party, thereby allowing the reimbursing party to identify the party to be 
reimbursed without knowing his credit card account identifier. 

Referring to FIG. 7, a table 160 illustrates an embodiment of the billing statement 
5 database 38 (FIG. 2). The table 160 includes entries 162 and 164, each of which describes 

information to appear on a billing statement. It will be understood by those skilled in the art that 
the table 160 may include any number of entries. Each of the entries 162 and 164 defines (i) a 
transaction identifier 1 70 that uniquely indicates a transaction that is to appear on a billing 
statement, and that corresponds to a transaction identifier 110 (FIG. 5) of the transaction 

1 0 database 34; (ii) a transaction amount 1 72 indicating the amount of the transaction; (iii) a charge 
amount 174 which indicates a portion of the transaction amount 172 that is applied to a financial 
account; (iv) a party to charge 176 which indicates a party to pay the charge amount 174; (v) a 
billing destination 1 78 that indicates a destination (if any) to which the corresponding billing 
statement is sent; and (vi) a payment status 1 80 indicating whether and/or when a bill has been 

1 5 sent to the indicated party, and whether and/or when payment for the charge amount 1 74 has 
been received by the billing party. As will be apparent to those skilled in the art, further 
information may be stored for each entry. 

The party to charge 176 is an identifier that corresponds to one of (i) the account 
identifier 64 (FIG. 3) of the account holder database 30; and (ii) the reimbursing party identifier 

20 90 (FIG. 4) of the reimbursing party database 32. Thus, the party to charge 176 indicates an 

account holder or a reimbursing party. Similarly, the billing destination 178 corresponds to one 
of (i) the account holder billing address 68 (FIG. 3) of the account holder database 30; and (ii) 
the billing destination 148 (FIG. 6) of the reimbursing party database 32. Thus, further 
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information regarding a party to charge or a billing destination may be readily determined from 
databases described above. 

In accordance with entries of the billing statement database 38, billing statements 
may be printed on the printer 26 (FIG. 2) as appropriate. For example, if a billing destination 
5 indicates a postal address, a billing statement may be printed and mailed to the postal address. 
Billing statements may also be transmitted via a network, such as the Internet. For example, if a 
billing destination indicates an electronic mail address, a billing statement may be generated and 
sent to the electronic mail address. 

Referring to FIG. 8, a process 200 performed by the billing server 14 (FIG. 1) 

10 initiates when charge data is received (step 202) from the CAT 12 processing a transaction. The 
charge data typically includes a transaction amount and an account identifier that specifies an 
account holder's financial account. The charge data may further include a merchant identifier 
that uniquely identifies the merchant. Upon receiving the charge data, the billing server 14 may 
generate a transaction identifier that uniquely identifies the transaction. Alternatively, the charge 

1 5 data may include a transaction identifier. The charge data and transaction identifier are stored in 
the transaction database 34. 

The billing server 14 then determines whether there are any reimbursement rules 
corresponding to the account identifier (step 204), and thus determines whether there are any 
reimbursement rules corresponding to the financial account. For example, the received account 

2 0 identifier may be compared with records of the reimbursement rules database 36 to find a record 
that includes the account identifier. For example, the table 130 (FIG. 6) represents a record that 
includes an account identifier "1111-1111-1111-1111". 



18 



If there are not any reimbursement rules corresponding to the financial account, 
then the account holder's financial account is charged in a conventional manner with the 
transaction amount (step 206). If there are reimbursement rules corresponding to the financial 
account, then the billing server 14 determines whether any of the reimbursement rules are 
5 satisfied (step 208). As described above, each record of the reimbursement rules database 36 
includes one or more entries. Each entry describes a reimbursement rule and includes a 
reimbursement condition. A reimbursement rule is satisfied if the corresponding reimbursement 
condition is satisfied by the transaction. 

If a reimbursement rule is satisfied, the reimbursing party corresponding to that 

1 0 reimbursement rule is determined (step 210). Thus, if an entry includes a reimbursement 

condition that is satisfied by the transaction, then the reimbursing party is determined from the 
reimbursing party identifier of the entry . Similarly, a reimbursement amount is also determined 
from the satisfied reimbursement rule (step 212). 

The reimbursement amount is charged to the reimbursing party (step 214). 

1 5 Charging the reimbursing party may comprise generating an entry for insertion into the billing 
statement database 38 (FIG. 2). Such an inserted entry would include (i) the transaction 
identifier generated by the billing server 14, (ii) the transaction amount received in step 202, (iii) 
a charge amount which is the reimbursement amount determined in step 212; (iv) the party to 
charge, which is the reimbursing party; and (v) the billing destination which is determined with 

2 0 reference to the billing destination 148 (FIG. 6) of the appropriate entry in the reimbursement 
rules database 36. 

The difference between the transaction amount and the reimbursement amount is 
likewise charged to the account holder (step 216). Charging the account holder may comprise 
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generating an entry for insertion into the billing statement database 38 (FIG. 2). Such an inserted 
entry would include (i) the transaction identifier generated by the billing server, (ii) the 
transaction amount received in step 202, (iii) a charge amount which is the difference between 
the transaction amount and the reimbursement amount determined in step 212; (iv) the party to 
5 charge, which is the account holder and may be identified by the account identifier received in 
step 202; and (v) the billing destination which is determined with reference to the account holder 
billing address 68 (FIG. 3) of the appropriate entry in the account holder database 30. 

In one embodiment, the available balance of the account holder may be compared 
with the difference between the transaction amount and the reimbursement amount. If the 

1 0 account holder does not have a sufficient available balance, then the charge would be denied. 

For example, referring again to FIG. 5, the entry 106 of the transaction database 
34 defines the transaction identified by the transaction identifier "123456", and also indicates 
that the transaction amount is $150. Further, the SIC code of the merchant indicates that the 
merchant is a "medical care provider". Referring again to FIG. 6, shown therein are the 

1 5 reimbursement rules applicable to the appropriate account holder. Particularly, the entry 1 38 
indicates that 95% of the transaction amount is to be reimbursed by the reimbursing party 
"R730" if the merchant participating in the transaction is a medical care provider. Since the 
transaction "123456" identified above satisfies this reimbursement condition, reimbursement is 
to be made and thus the reimbursing party "R730" is to be charged accordingly. Referring again 

20 to FIG. 7, the entries 1 62 and 1 64 of the billing statement database 38 correspond to the 

transaction "123456" which has resulted in charges to two financial accounts. The transaction 
amount $150 is reflected in each of the entries 162 and 164. The charge amount for the party 
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identified by "R730" is $142.50 (95% of the transaction amount). The charge amount for the 
party identified by "1 1 1 1-1 1 1 1-1 1 1 1-1 1 1 1" is $7.50 ($150.00 - $142.50). 

The above-described process 200 may be performed during the time that a 
transaction is initiated and concludes at the CAT 12. Alternatively, steps of the process 200 may 
5 be performed some time after the transaction has concluded. For example, the billing server 14 
may determine, on a monthly basis, whether any transaction described in the transaction database 
34 (FIG. 2) should be reimbursed, as described above. If so, the appropriate reimbursing parties 
would be charged accordingly. 

In the description above, a plurality of financial accounts could each be charged 
1 0 portions of a transaction amount based on whether the transaction satisfied rules stored by the 
billing server 14 (FIGS. 1 and 2). In other embodiments, a plurality of financial accounts could 
each be charged portions of a transaction amount based on whether authorization is received 
from the reimbursing party or another party. As will be apparent to those skilled in the art, the 
reimbursement rules database may define both reimbursement rules that do not require approval, 
1 5 and reimbursement rules that do. 

Referring to FIG. 9, in another embodiment a reimbursement system 228 includes 
the billing server 14 that is in communication with the card authorization terminal 12 and with a 
reimbursing party device 230. The reimbursing party device 230 may be a computer, telephone 
or other device that may receive an approval request from the billing server 14 and transmit a 
20 response to the billing server 14. 

Referring to FIG. 10, a table 240 illustrates a record included in another 
embodiment of the reimbursement rules database 36 (FIG. 2). Each record defines the 
reimbursement rules for a particular financial account. The table 240 includes an account 
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identifier 242 that uniquely identifies the financial account, and which corresponds to an account 
identifier of the account holder database 30 (FIG. 2). In the exemplary record depicted in FIG. 
1 0, the account identifier is " 1 1 1 1 - 1 1 1 1 - 1 1 1 1 - 1 1 11 ", which corresponds to the account identifier 
of the entry 52 (FIG. 3) of the account holder database 30. 
5 The table 240 also includes entries 244, 246, 248 and 250, each of which 

describes a reimbursement rule. It will be understood by those skilled in the art that the table 
240 may include any number of entries. Each of the entries 244, 246, 248 and 250 defines (i) a 
reimbursing party identifier 252 that uniquely indicates a reimbursing party, and which 
corresponds to a reimbursing party identifier 90 (FIG. 4) of the reimbursing party database 32; 

1 0 (ii) a reimbursement condition 254; (iii) a communication address for approval request 256; (iv) 
a reimbursement amount 258; (v) a billing destination 260; (vi) time to reimburse 262; and (vii) 
an account alias 264. As will be apparent to those skilled in the art, further information may be 
stored for each reimbursement rule. 

Contrary to the embodiment illustrated in FIG. 6, in the embodiment illustrated in 

1 5 FIG. 1 0 reimbursement rules indicate a communication address to which a request for approval 
is sent if the transaction satisfies the corresponding reimbursement condition. For example, the 
entry 244 indicates that a request for approval is sent to the electronic mail address 
"finance@corpx.com". The entry 246 similarly indicates that a request for approval is 
communicated to the telephone number "(203) 555-1234". Telephone numbers may permit a 

2 0 request for approval to be sent to a facsimile machine, to a live operator or to an interactive 
voice-response unit. 

The reimbursing party device 230 (FIG. 9) receives the request for approval, and 
in turn sends to the billing server 14 a response to the request for approval. If the response 
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indicates that the reimbursing party has approved the request, then the reimbursing party is 
charged the reimbursement amount specified by the reimbursement rule. The received response 
indicates approval or rejection (e.g. a "yes" or a "no" response), and may also indicate further 
information, such as (i) a financial account from which funds may be transferred to the billing 
5 party, or (ii) other information typically included in the reimbursement rules database 36 (FIG. 
2), such as a reimbursement amount. If the response indicates a financial account from which 
funds may be transferred to the billing party, then funds may be transferred automatically, and 
consequently the reimbursement amount is paid. 

In some embodiments, the response may also include an indication of the 

1 0 reimbursement amount to be charged to the reimbursing party. In such embodiments, a 

reimbursement amount need not be stored in the corresponding entry of the reimbursement rules 
database 36. The response may also include bearer instrument that is a form of "digital money", 
also known as "e-cash". Digital money is typically an encrypted digital file containing a list of 
digital representations of specified amounts of money, each recorded by an issuing bank. A 

1 5 description of different types of "digital money" may be found in "Digital Money, The New Era 
of Internet Commerce", by Daniel C. Lynch and Leslie Lundquist, and in "Electronic Payment 
Systems", by Donald O'Mahony, Michael Peirce and Hitesh Tewari. In such an embodiment, not 
only is the reimbursement amount indicated by the received response, but the payment itself is 
received in the response, so the reimbursing party does not need to be charged for the 

20 reimbursement amount. 

Referring to FIGS. 1 1A and 1 IB, a process 260 performed by the billing server 14 
(FIG. 1) initiates when charge data is received (step 262) from the CAT 12 processing a 
transaction. The charge data typically includes a transaction amount and an account identifier 
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that specifies an account holder's financial account. Upon receiving the charge data, the billing 
server 14 may generate a transaction identifier that uniquely identifies the transaction. 
Alternatively, the charge data may include the transaction identifier. The billing server 14 then 
determines whether there are any reimbursement rules corresponding to the account identifier 
5 (step 264), and thus determines whether there are any reimbursement rules corresponding to the 
financial account. For example, the received account identifier may be compared with records of 
the reimbursement rules database 36 to find a record that includes the account identifier. 

If there are not any reimbursement rules corresponding to the financial account, 
then the account holder's financial account is charged in a conventional manner with the 

1 0 transaction amount (step 266). If there are reimbursement rules corresponding to the financial 
account, then the billing server 14 determines whether any of the reimbursement rules are 
satisfied (step 267). As described above, each record of the reimbursement rules database 36 
includes one or more entries. Each entry describes a reimbursement rule and includes a 
reimbursement condition. A reimbursement rule is satisfied if the corresponding reimbursement 

1 5 condition is satisfied by the transaction. 

If a reimbursement rule is satisfied, the communication address and reimbursing 
party corresponding to that reimbursement rule are determined (steps 268 and 270, respectively). 
Thus, if an entry includes a reimbursement condition that is satisfied by the transaction, then the 
communication address and reimbursing party are determined from the reimbursing party 

2 0 identifier of the entry. 

The billing server 14 sends a request for approval to the communication address 
(step 272), and a response thereto is received (step 274). If it is determined that digital money is 
not included in the response (step 276), then the reimbursement amount is otherwise determined 
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(e.g., from the response or reimbursement rules database 36) (step 278). The reimbursement 
amount is charged to the reimbursing party (step 280). If digital money is included in the 
response, then the amount of digital money is determined (step 282), and the reimbursement 
amount is set to be this digital money amount (step 284). The difference between the transaction 
5 amount and the reimbursement amount is charged to the account holder (step 286). 

In another embodiment, the charge data received from the CAT 12 may include a 
signal that indicates approval to charge at least a portion of the transaction amount to a second 
financial account. In such an embodiment, the billing server would not send a request for 
approval to a communication address, since approval has already been received. 

1 o Referring to FIG. 1 2, a table 280 represents other exemplary information included 

in the billing statement database 38. The table 280 includes entries 282 and 284 that correspond 
to a transaction identified by the transaction identifier "987654". Referring again to FIG. 5, the 
entry 104 of the transaction database 34 defines the transaction identified by the transaction 
identifier "987654", and also indicates that the transaction amount is $125. Further, the SIC code 

15 of the merchant indicates that the merchant is a "restaurant". Referring again to FIG. 10, shown 
therein are the reimbursement rules applicable to the appropriate account holder. Particularly, 
the entry 246 indicates that the transaction amount, up to $100, is to be reimbursed by the 
reimbursing party "R729" if the merchant participating in the transaction is a restaurant. Since 
the transaction "987654" identified above satisfies this reimbursement condition, reimbursement 

20 is to be made and thus the reimbursing party "R729" is to be charged accordingly. Referring 
again to FIG. 12, the entries 282 and 284 of the billing statement database 38 correspond to the 
transaction "987654" which has resulted in charges to two financial accounts. The transaction 
amount $125 is reflected in each of the entries 282 and 284. The charge amount for the party 
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identified by "R729" is $100 (the maximum to be reimbursed according to the entry 246 of FIG. 
1 0). The charge amount for the party identified by "11 1 1-1 1 1 1-1 111-1 1 11" is $25 ($125 - 
$100). 

FIG. 13 represents an exemplary billing statement 300 printed for the reimbursing 
5 party in accordance with the entry 282 (FIG. 12) of the billing statement database 38. Those 
skilled in the art will understand that a billing statement may include information that differs 
from the below-described exemplary billing statements. The billing statement 300 includes 
indicia indicating an account number 301 (which is an account alias), a transaction identifier 302, 
a transaction date 304, a transaction description 306, a merchant identifier 308, an amount 

1 0 charged 3 1 0 and a billing destination 312. The indicia may be printed on the printer 26 (FIG. 2) 
based on (i) data stored in the billing statement database 38, such as the transaction identifier 170 
and the charge amount 174 (FIGS. 7 and 12), (ii) data stored in the transaction database 34, such 
as the merchant identifier 1 12, transaction date 1 16 and the transaction description 1 18 (FIG. 5), 
and (iii) data stored in the reimbursement rules database 36, such as the billing destination 148 

1 5 and the account alias 1 52. 

FIG. 14 represents an exemplary billing statement 320 printed for the party to be 
reimbursed in accordance with the entry 284 (FIG. 12) of the billing statement database 38. The 
billing statement 320 includes indicia indicating the corresponding account identifier 321. 
transaction identifier 322, transaction date 324, transaction description 326, merchant identifier 

2 0 328, transaction amount 330, amount charged 332 and billing destination 334. The indicia may 
be printed on the printer 26 (FIG. 2) based on (i) data stored in the billing statement database 38, 
such as the transaction identifier 170, transaction amount 172 and the charge amount 174 (FIGS. 
7 and 12), (ii) data stored in the transaction database 34, such as the merchant identifier 1 12, 
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transaction date 116 and the transaction description 1 1 8 (FIG. 5), and (iii) data stored in the 
reimbursement rules database 36, such as the billing destination 148. 

As described above, an account alias may be stored for each reimbursement rule. 
For example, each entry of the reimbursement rules database 36 includes a corresponding 
5 account alias 1 52 (FIG. 6). In another embodiment, each financial account may have a single 
account alias that is revealed to appropriate reimbursing parties. 

Referring to FIG. 1 5, a table 350 represents an account alias database storing 
account identifiers 352 and corresponding account aliases 354. In embodiments which use such 
an account alias database, a party to be reimbursed has a corresponding account alias that is 

1 0 revealed to all appropriate reimbursing parties. The account alias database may be stored in the 
data storage device 22. In other embodiments, an account alias may be generated by applying a 
"one-way hash function" to the account identifier, or by otherwise encrypting or encoding the 
account identifier. Many appropriate cryptographic techniques are described in "Applied 
Cryptography, Protocols, Algorithms. And Source Code In C", by Bruce Schneier. 

15 Referring to FIG. 16, a process 400 is performed by the billing server 14 (FIG. 1) 

at periodic or predetermined intervals to determine whether any reimbursing parties have not 
paid the amounts they were charged. The billing server 14 identifies an entry in the billing 
statement database 38 (FIG. 2) that indicates an unpaid charge (step 402). If it is determined that 
the entry does not correspond to a reimbursing party (step 404), then the unpaid amount was 

2 0 charged to an account holder, and collection from the account holder is pursued in a conventional 
manner (step 406). If the entry does correspond to a reimbursing party, then it is also determined 
whether the time to reimburse has expired (step 408). If so, then the unpaid amount is charged to 
the corresponding account holder (step 410). The corresponding account holder may be 
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determined from the entry by searching the billing statement database 38 for another entry that 
indicates the same transaction. Such an embodiment assures that liability for unpaid 
reimbursement amounts rests with the account holder. As described above, in an alternate 
embodiment the reimbursing party may be held liable, rather than the corresponding party to be 
5 reimbursed. If there are any unpaid entries remaining in the billing statement database 38 (step 
412), then the above-described steps are repeated. When no unpaid entries remain, the process 
400 ends (step 414). 

Although the present invention has been described with respect to a preferred 
embodiment thereof, those skilled in the art will note that various substitutions may be made to 
1 0 those embodiments described herein without departing from the spirit and scope of the present 
invention. For example, the present invention is applicable to debit card accounts as well as 
credit card accounts. In addition, an account holder may be reimbursed by more than one 
reimbursing party. 
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What is claimed is: 



1 1 . A method for processing a charge applied to a financial account, the method comprising: 

2 receiving charge data; and 

3 charging a plurality of financial accounts based on the charge data. 

1 2. The method of claim 1 , in which the charge data indicates a first financial account and the 

2 plurality of financial accounts includes the first financial account. 

13. A method for processing a charge applied to a financial account, the method comprising: 

2 receiving charge data that indicates a transaction amount and a first financial account; 

3 determining a second financial account that corresponds to the first financial account; 

4 determining a reimbursement amount that corresponds to the first financial account; 

5 applying to the first financial account a first charge amount that is based on a difference 

6 between the transaction amount and the reimbursement amount; and 

7 applying to the second financial account a second charge amount based on the 

8 reimbursement amount. 

1 4. The method of claim 3, further comprising: 

2 determining a reimbursement rule that corresponds to the charge data; and 

3 determining if the charge data satisfies the reimbursement rule; 

4 and in which the step of applying to the second financial account a second charge amount is 

5 performed if the charge data satisfies the reimbursement rule. 
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1 5. The method of claim 4, in which the reimbursement rule specifies a first merchant 

2 identifier, and in which the charge data specifies a second merchant identifier; 

3 and in which the step of determining if the charge data satisfies the reimbursement rule 

4 comprises: 

5 determining whether the first merchant identifier corresponds to the second merchant 

6 identifier. 

1 6. The method of claim 3, in which the charge data indicates a transaction date; 

2 and further comprising: 

3 applying to the first financial account the second charge amount after a predetermined 

4 time after the transaction date. 

1 7. The method of claim 6, in which the step of applying to the first financial account the 

2 second charge amount is performed if the second charge amount has not been paid before a 

3 predetermined time. 

1 8. The method of claim 3, in which the charge data further includes a signal that indicates 

2 approval to charge at least a portion of the transaction amount to the second financial account. 

19. A method for processing a charge applied to a financial account, the method comprising: 

2 receiving charge data that indicates a first financial account; 

3 determining a second financial account that corresponds to the first financial account; and 

4 applying to the second financial account an amount based on the charge data. 
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1 10. The method of claim 9, further comprising: 

2 determining a reimbursement rule that corresponds to the charge data; and 

3 determining if the charge data satisfies the reimbursement rule; 

4 and in which the step of applying is performed if the charge data satisfies the reimbursement 

5 rule. 

1 11. The method of claim 1 0, in which the reimbursement rule specifies a first merchant 

2 identifier, and in which the charge data specifies a second merchant identifier; 

3 and in which the step of determining if the charge data satisfies the reimbursement rule 

4 comprises: 

5 determining whether the first merchant identifier corresponds to the second merchant 

6 identifier. 

1 12. The method of claim 9, in which the charge data further includes a signal that indicates 

2 approval to charge the second financial account. 

1 13. The method of claim 9, in which the charge data indicates a transaction date; 

2 and further comprising: 

3 applying to the first financial account the amount based on the charge data after a 

4 predetermined time. 
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1 14. The method of claim 13, in which the step of applying to the first financial account the 

2 amount based on the charge data is performed if the second charge amount has not been paid 

3 before a predetermined time. 

1 15. A method for processing a charge applied to a financial account, the method comprising: 

2 receiving charge data that indicates a transaction amount; 

3 determining a reimbursement rule that corresponds to the charge data; and 

4 apportioning the transaction amount among a plurality of financial accounts in 

5 accordance with the reimbursement rule. 

1 1 6. The method of claim 1 5, in which the step of apportioning is performed if the charge data 

2 satisfies the reimbursement rule. 

1 1 7. The method of claim 16, in which the reimbursement rule specifies a first merchant 

2 identifier, and in which the charge data specifies a second merchant identifier; 

3 and in which the step of determining if the charge data satisfies the reimbursement rule 

4 comprises: 

5 determining whether the first merchant identifier corresponds to the second merchant 

6 identifier. 

1 18. The method of claim 15, further comprising: 

2 determining the plurality of financial accounts from the reimbursement rule. 
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1 1 9. The method of claim 1 5, in which the charge data further includes a signal that indicates 

2 approval to apportion the transaction amount among the plurality of financial accounts. 

1 20. A method for processing a charge applied to a financial account, the method comprising: 

2 receiving charge data; 

3 determining a reimbursement rule that corresponds to the charge data; 

4 determining if the charge data satisfies the reimbursement rule; and 

5 charging at least one of a plurality of financial accounts in accordance with the charge 

6 data if the charge data satisfies the reimbursement rule. 

1 21 . The method of claim 20. in which the reimbursement rule specifies a first merchant 

2 identifier, and in which the charge data specifies a second merchant identifier; 

3 and in which the step of determining if the charge data satisfies the reimbursement rule 

4 comprises: 

5 determining whether the first merchant identifier corresponds to the second merchant 

6 identifier. 

1 22. The method of claim 20, in which the charge data includes a signal that indicates 

2 approval to charge the at least one of the plurality of financial accounts. 

1 23. A method for processing a charge applied to a financial account, the method comprising: 

2 receiving charge data; 

3 determining a communication address that corresponds to the charge data; 
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4 sending a request for approval to the communication address; 

5 receiving a response to the request for approval; and 

6 charging at least one of a plurality of financial accounts in accordance with the received 

7 response. 

1 24. The method of claim 23, in which the communication address is an electronic mail 

2 address. 

1 25. The method of claim 23, in which the communication address is a telephone number. 

1 26. The method of claim 23, in which the response includes digital money. 

1 27. The method of claim 23, in which the step of charging a plurality of financial accounts in 

2 accordance with the received response comprises: 

3 determining from the received response an amount to charge each financial account. 

1 28. The method of claim 23, in which the request for approval includes at least a portion of 

2 the charge data. 

1 29. The method of claim 23, in which the request for approval includes an account alias. 

1 30. A method for processing a charge applied to a financial account, the method comprising: 

2 receiving charge data that indicates a first financial account; 
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3 



determining a communication address that corresponds to the charge data; 



4 



sending a request for approval to the communication address; 



5 



receiving a response to the request for approval, the response including a signal 



6 representing digital money; 



7 



determining an amount of the digital money; and 



8 



charging the first financial accounts in accordance with the amount of the digital money. 



1 31. The method of claim 30, in which the charge data further indicates a transaction amount; 

2 and in which the step of charging comprises: 



4 transaction amount and the amount of the digital money. 

1 32. The method of claim 30, in which the request for approval includes at least a portion of 

2 the charge data. 

1 33. The method of claim 30, in which the request for approval includes an account alias of 

2 the first financial account. 

1 34. A method for processing a charge applied to a financial account, the method comprising: 

2 processing a plurality of entries, each entry including charge data that indicates a 

3 transaction amount and a first financial account; 

4 for each entry, determining if there is a second financial account that corresponds to the 

5 first financial account; and 
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charging the first financial accounts in accordance with a difference between the 
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6 if there is a second financial account for the entry 

7 determining a reimbursement amount that corresponds to the first financial 

8 account; 

9 applying to the first financial account a first charge amount that is based on a 

1 0 difference between the transaction amount and the reimbursement amount; and 

1 1 applying to the second financial account a second charge amount based on the 

12 reimbursement amount. 

1 35. A method for processing a charge applied to a financial account, the method comprising 

2 receiving charge data; and 

3 determining from the charge data a number of financial accounts to be charged in 

4 accordance with the charge data. 

1 36. An apparatus for processing a charge applied to a financial account, comprising: 

2 a storage device; and 

3 a processor connected to the storage device, 

4 the storage device storing a program for controlling the processor; and 

5 the processor operative with the program to: 

6 receive charge data; and 

7 charge a plurality of financial accounts based on the charge data. 

1 37. A computer readable medium encoded with processing instructions for implementing a 

2 method for processing a charge applied to a financial account, the method comprising: 
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3 receiving charge data; and 

4 charging a plurality of financial accounts based on the charge data. 

1 38. An apparatus for processing a charge applied to a financial account, comprising: 

2 a storage device; and 

3 a processor connected to the storage device. 

4 the storage device storing a program for controlling the processor; and 

5 the processor operative with the program to: 

6 receive charge data that indicates a transaction amount and a first financial 

7 account; 

8 determine a second financial account that corresponds to the first financial 

9 account; 

1 0 determine a reimbursement amount that corresponds to the first financial account; 

1 1 apply to the first financial account a first charge amount that is based on a 

1 2 difference between the transaction amount and the reimbursement amount; and 

1 3 apply to the second financial account a second charge amount based on the 

1 4 reimbursement amount. 

1 39. A computer readable medium encoded with processing instructions for implementing a 

2 method for processing a charge applied to a financial account, the method comprising: 

3 receiving charge data that indicates a transaction amount and a first financial account; 

4 determining a second financial account that corresponds to the first financial account; 

5 determining a reimbursement amount that corresponds to the first financial account; 
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6 applying to the first financial account a first charge amount that is based on a difference 

7 between the transaction amount and the reimbursement amount; and 

8 applying to the second financial account a second charge amount based on the 

9 reimbursement amount. 

1 40. An apparatus for processing a charge applied to a financial account, comprising: 

2 a storage device; and 

3 a processor connected to the storage device, 

4 the storage device storing a program for controlling the processor; and 

5 the processor operative with the program to: 

6 receive charge data that indicates a first financial account; 

7 determine a second financial account that corresponds to the first financial 

8 account; and 

9 apply to the second financial account an amount based on the charge data. 

1 41 . A computer readable medium encoded with processing instructions for implementing a 

2 method for processing a charge applied to a financial account, the method comprising: 

3 receiving charge data that indicates a first financial account; 

4 determining a second financial account that corresponds to the first financial account; and 

5 applying to the second financial account an amount based on the charge data. 

1 42. An apparatus for processing a charge applied to a financial account, comprising: 

2 a storage device; and 
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3 a processor connected to the storage device, 

4 the storage device storing a program for controlling the processor; and 

5 the processor operative with the program to: 

6 receive charge data that indicates a transaction amount; 

7 determine a reimbursement rule that corresponds to the charge data; and 

8 apportion the transaction amount among a plurality of financial accounts in 

9 accordance with the reimbursement rule. 

1 43. A computer readable medium encoded with processing instructions for implementing a 

2 method for processing a charge applied to a financial account, the method comprising: 

3 receiving charge data that indicates a transaction amount; 

4 determining a reimbursement rule that corresponds to the charge data; and 

5 apportioning the transaction amount among a plurality of financial accounts in 

6 accordance with the reimbursement rule. 

1 44. An apparatus for processing a charge applied to a financial account, comprising: 

2 a storage device; and 

3 a processor connected to the storage device, 

4 the storage device storing a program for controlling the processor; and 

5 the processor operative with the program to: 

6 receive charge data; 

7 determine a reimbursement rule that corresponds to the charge data; 

8 determine if the charge data satisfies the reimbursement rule; and 
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9 charge at least one of a plurality of financial accounts in accordance with the 

1 0 charge data if the charge data satisfies the reimbursement rule. 

1 45. A computer readable medium encoded with processing instructions for implementing a 

2 method for processing a charge applied to a financial account, the method comprising: 

3 receiving charge data; 

4 determining a reimbursement rule that corresponds to the charge data; 

5 determining if the charge data satisfies the reimbursement rule; and 

6 charging at least one of a plurality of financial accounts in accordance with the charge 

7 data if the charge data satisfies the reimbursement rule. 

1 46. An apparatus for processing a charge applied to a financial account, comprising: 

2 a storage device; and 

3 a processor connected to the storage device, 

4 the storage device storing a program for controlling the processor; and 

5 the processor operative with the program to: 

6 receive charge data; 

7 determine a communication address that corresponds to the charge data; 

8 send a request for approval to the communication address; 

9 receive a response to the request for approval; and 

I o charge at least one of a plurality of financial accounts in accordance with the 

I I received response. 
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1 47. A computer readable medium encoded with processing instructions for implementing a 

2 method for processing a charge applied to a financial account, the method comprising: 

3 receiving charge data; 

A determining a communication address that corresponds to the charge data; 

5 sending a request for approval to the communication address; 

6 receiving a response to the request for approval; and 

7 charging at least one of a plurality of financial accounts in accordance with the received 

8 response. 

1 48. An apparatus for processing a charge applied to a financial account, comprising: 

2 a storage device; and 

3 a processor connected to the storage device, 

4 the storage device storing a program for controlling the processor; and 

5 the processor operative with the program to: 

6 receive charge data that indicates a first financial account; 

7 determine a communication address that corresponds to the charge data; 

8 send a request for approval to the communication address; 

9 receive a response to the request for approval, the response including a signal 

1 0 representing digital money; 

1 1 determine an amount of the digital money; and 

1 2 charge the first financial accounts in accordance with the amount of the digital 

13 money. 
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1 49. A computer readable medium encoded with processing instructions for implementing a 

2 method for processing a charge applied to a financial account, the method comprising: 

3 receiving charge data that indicates a first financial account; 

4 determining a communication address that corresponds to the charge data; 

5 sending a request for approval to the communication address; 

6 receiving a response to the request for approval, the response including a signal 

7 representing digital money; 

8 determining an amount of the digital money; and 

9 charging the first financial accounts in accordance with the amount of the digital money. 

1 50. An apparatus for processing a charge applied to a financial account, comprising: 

2 a storage device; and 

3 a processor connected to the storage device, 

4 the storage device storing a program for controlling the processor; and 

5 the processor operative with the program to: 

6 process a plurality of entries, each entry including charge data that indicates a 

7 transaction amount and a first financial account; 

8 for each entry, determine if there is a second financial account that corresponds to 

9 the first financial account; and 

10 if there is a second financial account for the entry 

1 1 determine a reimbursement amount that corresponds to the first financial account; 

12 apply to the first financial account a first charge amount that is based on a 

1 3 difference between the transaction amount and the reimbursement amount; and 
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1 4 a Pply to the second financial account a second charge amount based on the 

1 5 reimbursement amount. 

1 51. A computer readable medium encoded with processing instructions for implementing a 

2 method for processing a charge applied to a financial account, the method comprising: 

3 processing a plurality of entries, each entry including charge data that indicates a 

4 transaction amount and a first financial account; 

5 for each entry, determining if there is a second financial account that corresponds to the 

6 first financial account; and 

7 if there is a second financial account for the entry 

8 determining a reimbursement amount that corresponds to the first financial 

9 account: 

1 0 applying to the first financial account a first charge amount that is based on a 

1 1 difference between the transaction amount and the reimbursement amount; and 

12 applying to the second financial account a second charge amount based on the 

1 3 reimbursement amount. 

1 52. An apparatus for processing a charge applied to a financial account, comprising: 

2 a storage device; and 

3 a processor connected to the storage device, 

4 the storage device storing a program for controlling the processor; and 

5 the processor operative with the program to: 

6 receive charge data; and 
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7 determine from the charge data a number of financial accounts to be charged in 

8 accordance with the charge data. 



1 53. A computer readable medium encoded with processing instructions for implementing a 

2 method for processing a charge applied to a financial account, the method comprising: 

3 receiving charge data; and 

4 determining from the charge data a number of financial accounts to be charged in 

5 accordance with the charge data. 



44 



ABSTRACT OF THE DISCLOSURE 

A billing server receives charge data from a card authorization terminal. The 
charge data indicates a transaction amount, such as a purchase price, and a first financial account, 
such as a credit card account. The billing server determines a second financial account that 
5 corresponds to the first financial account. For example, the second financial account may be the 
financial account of an insurance company or other reimbursing party. The billing server also 
determines a reimbursement amount that corresponds to the first financial account. The second 
financial account is charged the reimbursement amount. Thus, a portion or all of the transaction 
amount is paid by a reimbursing party. The second financial account is only charged if a 
1 0 reimbursement rule is satisfied. For example, only purchases made at certain types of merchants 
may be reimbursed. In addition, the billing server may first request approval before charging the 
second financial account. 
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Please address all written correspondence to: 



Dean Alderucci 

Walker Digital Corporation 

Five High Ridge Park 

Stamford, Connecticut 06905-1326 

Phone (203) 705-3006 

Fax (203) 595-8266 

Wherefore I pray that Letters Patent be granted to me for the invention or discovery described and claimed in 
the foregoing specification and claims, and I hereby subscribe my name to the foregoing specification and 
claims, declaration, power of attorney, and this petition. 

Full name of sole or first inventor: Magdalena MIK 
Residence: 168 South Wind Drive, Wallingford, CT 06492 
Post Office Address: same as above 
Citizenship: U.S.A. 

Inventor's signature^ 



Full name of second inventor: Jay S. WALKER 
Residence: 124 Spectacle Lane, Ridgefield, CT 06877 
Post Office Address: same as above 
Citizenship: U.S.A. 



Inventor's signature 




Date June 16, 1998 



Date June 16, 1998 



Full name of third inventor: Daniel E. TEDESCO 
Residence: 192 Park Street, Apt. 6, New Canaan, CT, 06840 
Post Office Address: same as above 
Citizenship: U.S.A. 



Inventor's signature 



Full name of fourth inventor: Andrews. VAN LUCHENE 
Residence: 13-2a Clarmore Drive, Norytelk, CT 06850 
Post Office Address: same as above , 
Citizenship. U.S.A. 




Date June 16, 1998 



Inventor's signature 




Date June 16, 1998 



Full name of fifth inventor: James A. JORASCH 
Residence: 25 Forest Street, Apt. 5G, Stamford, CT 06901 
Post Office Address' same as above 
Citizenship: U.S A 

Inventor's signature 




Date June 16, 1998 



Applicant or Patentee: Magdalena Mik, et al. Docket No. WD2-98-017 

Serial/Patent No.: Not Yet Assigned 

Filed/Issued: June 16, 1998 

For: System and Method for Processing a Charge Applied to a Financial Account 

VERIFIED STATEMENT (DECLARATION) CLAIMING SMALL ENTITY 
STATUS (37 CFR 1.9(0 and 1.27(c)) - SMALL BUSINESS CONCERN 



I hereby declare that I am 

/SL^ the owner of the small business concern identified below 
□ an official of the small business concern empowered to act on behalf of the concern identified below: 

NAME OF CONCERN: Walker Asset Management Limited Partnership 



ADDRESS OF CONCERN' Four High Ridge Park. Stamford, CT 06905-1325 



I hereby declare that the above identified small business concern qualifies as a small business concern as defined in 13CFR 121.3-18, and 
reproduced in 37 CFR 1.9 (d), for purposes of paying reduced fees under section 41(a) and (b) of Title 35, United States Code, in that the 
number of employees of the concern, including those of its affiliates, does not exceed 500 persons For purposes of this statement, (1) the 
number of employees of the business concern is the average over the previous fiscal year of the concern of the persons employed on a full- 
time, part-time or temporary basis during each of the pay periods of the fiscal year, and (2) concerns are affiliates of each other when either, 
directly or indirectly, one concern controls or has the power to control the other, or a third party or parties controls or has the power to control 
both. 

I hereby declare that rights under contract or law have been conveyed to and remain with the small business concern identified abovewith 
regard to the invention, entitled by inventor(s) described in 



the specification filed herewith 

□ " application serial no. , filed 

□ patent no. , issued 



If the rights held by the above identified small business concern are not exclusive, each individual, concern or organization having rights to 
the invention is listed below* and no rights to the invention are held by any person, other than the inventor, who could not qualify as a small 
business concern under 37 CFR 1 9 (d) or by any concern which would not qualify as a small business concern under 37 CFR 1 9 (d) or a 
nonprofit organization under 37 CFR 1 9 (e) 

"NOTE. Separate verified statements are required from each named person, concern or organization having rights to the 
invention averring to their status as small entities (37 CFR 1 27) 

NAME 

ADDRESS 

□ Individual □ Small Business Concern □ Nonprofit Organization 

NAME 

ADDRESS 

□ Individual □ Small Business Concern □ Nonprofit Organization 

I acknowledge the duty to file, in this application or patent, notification of any change in status resulting in loss of entitlement to small entity 
status prior to paying, or at the time of paying, the earliest of the issue fee or any maintenance fee due after the date on which status as a 
small entity is no longer appropriate (37 CFR 1 .28 (b)) 

I hereby declare that all statements made herein of my own knowledge are true and that all statements made on information and belief are 
believed to be true, and further that these statements were made with the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under section 1001 of Title 18 of the United States Code, and that such willful false statements 
may jeopardize the validity of the application, any patent issuing thereon, or any patent to which this verified statement is directed 

NAME OF PERSON SIGNING Jay S Walker 



TITLE OF PERSON OTHER THAN OWNER President of Walker Digital Corp , as General Partner of Walker Asset Management 

Limited Partnership 

ADDRESS OF PERSON SIGNING Four High Ridge Park, Stamford, CT 06905 



SIGNATURE 



DATE June 16, 1998 



